A security token may be implemented in the form of a smart card, i.e., a portable medium having a semiconductor chip capable of performing desired operations and storing desired data. The semiconductor chip may have a Self Programmable One-chip Microcomputer (SPOM) architecture, which may enable securely handling multiple applications using self-programmable operations and storing data in a non-volatile memory.
The security token may be coupled by a token terminal to a station, for example, a computing platform, e.g., a Personal Computer (PC), or a cellular telephone. The token terminal may enable transferring data between the security token and the station. The token terminal may also provide the token with electrical power, and/or a clock signal, which may be needed for operating the security token.
The station or the terminal may include a user interface to receive an authentication code, e.g., a personal identification number (PIN) code, which may be used for authenticating a holder of the token.
The security token may enable performing a two-factor authentication of the user of the token, e.g., since in order to authenticate the user the user may be required to have possession of the token, as well as have the knowledge of the PIN code assigned to the token.
In order to authenticate and/or sign into a system, for example, a PC, a network, a security system of a building compound, a user may be required to couple a security token assigned personally to the user, to a token terminal of a station in the secured system. In addition, the user may have to enter a PIN code designated to the user (hereinafter referred to as “the user PIN”). The user PIN may include, for example, a series of digits and/or letters, e.g. 1, D, 4, 2.
The token may verify whether the PIN code entered by the user corresponds to the user PIN.
If a wrong PIN has been entered more than an allowed number of times, then the token may be locked, e.g., the token may not allow any additional attempts to enter the user PIN.
In order to unlock the token, a system administrator may provide the token with a second code, often referred to as “admin PIN”, “PUK” or “security officer” (SO) PIN. This process may be referred to as a one-factor authentication process, since it requires only one factor for authentication, i.e., knowledge of the admin PIN.
The one-factor authentication process outlined above may pose the following security risks: (1) knowledge of the admin PIN alone is sufficient in order to unlock a locked token; and (2) once the admin PIN is used to unlock the token, the admin PIN may be exposed. In some systems a unique admin PIN may be assigned to each user of the system. Although the use of different admin PIN codes for different users may enhance the security of the system, it may be a problem to securely store the different admin PINs in the system.
An authentication method, e.g., a challenge/response procedure may be used to address problem (2) mentioned above. The challenge/response method may include transmitting information (“the challenge”) from the token to the administrator. The challenge may include, for example, a random number generated by the token. The administrator may then encrypt the challenge using the admin PIN as a secret key. The administrator may then send the encrypted challenge, hereinafter referred to as “response”, back to the token. The token may decrypt the response, and may authenticate the admin PIN used by the administrator by comparing the decrypted response to the challenge.
Although unlocking the user token may be the most common administration operation, all of the above may hold for any other user-related administrative operation, such as personalizing a security token.